IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc, within the same session. By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP),
Existing cellular network deployments are dominated by the 2G and 3G standards. The process of rolling out so-called 4G networks has just begun, and it will be many years before 4G network coverage is sufficient to allow 2G and 3G networks to be withdrawn completely. A fundamental requirement for real-time service provision is the seamless handover of services for subscribers moving across cell boundaries of the radio access network (RAN). Given the ongoing co-existence of 2G, 3G and 4G networks, it is particularly desirable to allow for the handover of real-time service connections such as voice calls between the different radio access technologies.
Considering further the 4G technology, this is being specified under the name LTE (Long Term Evolution) and SAE (System Architecture Evolution) in 3GPP. The LTE radio access network technology implements only a packet switched access, in contrast to 2G and 3G (using GERAN and UTRAN radio access network technologies respectively) which provide for both packet switched and circuit switched access. In 2G and 3G networks, packet switched connections are used to carry data whilst circuit switched connections are used for real-time services such as voice calls. In 4G networks, all services will be carried via packet switched connections. In the case of a voice call initiated when a user is attached to a LTE radio access network (termed Enhanced UTRAN or E-UTRAN), that call will of course make use of a packet switched connection. If it is necessary for the call to be transferred to a 2G or 3G radio access network, e.g. because the user moves out of the coverage area of the E-UTRAN and into that of a GERAN or UTRAN network, the call must be switched from a packet switched (PS) access to a circuit switched (CS) access. Of course, the process for implementing the handover must be seamless such that little or no disruption of the call is perceived by the user. An appropriate access handover mechanism is also required in the case of the handover of a call from a PS access using a 3G UTRAN (HSPA) access network to a CS call using either 3G UTRAN access or 2G GSM access.
FIG. 1 illustrates schematically a scenario in which a user terminal (or User Equipment, UE, according to 3G terminology) initiates a voice call using a LTE radio access network and is subsequently handed over to a GSM/Edge Radio Access Network (GERAN). The call is established using the IMS network described above and which provides a common service control network for the PS and CS domains provided through the LTE, UTRAN, or GERAN radio accesses. In particular, the IMS includes a Multimedia Telephony (MMTel) Application Server which implements service logic for establishing and controlling voice calls. In order to implement the access handover, media control must be transferred from the Evolved Packet Core (EPC) network of the 4G domain to an allocated Mobile Switching Centre (MSC) within the 2G/3G domain. Other components illustrated in FIG. 1 are a Mobile Switching Centre Server (MSS) which has support for the GSM access network, an enhanced Node B (eNodeB) which provides inter alia control of radio access within the LTE RAN, a Serving/PDN gateway (S/P-GW), a Mobility Management Entity (MME) (both the S/P-GW and the MME reside within the EPC), and a Home Subscriber Server that resides within a subscriber's home network.
The SGW sits in the user plane where it forwards and routes packets to and from the eNodeB and the PDN GW. The S/P-GW also serves as the local mobility anchor for inter-eNodeB handovers and roaming between two 3GPP systems. The PDN GW (not shown in FIG. 1) acts as the interface between the radio network and the Packet Data Networks (PDNs), such as the Internet or SIP-based IP Multimedia Subsystem (IMS) networks (fixed and mobile). The PDN GW is the mobility anchor point for intra-3GPP access system mobility and for mobility between 3GPP access systems and non-3GPP access systems.
Interworking solutions for IMS Centralized Services (ICS) as specified in 3GPP TS 23.292, “IP Multimedia Subsystem (IMS) centralized services; Stage 2”, allows IMS sessions using CS bearers to be treated as standard IMS sessions, which is required for the purpose of IMS Service Continuity. ICS defines signalling mechanisms between the UE and IMS for transport of information to centralise the service in the IMS, and TS 23.237 “IP Multimedia Subsystem (IMS) Service Continuity” defines the additional procedures needed for service continuity when using CS access for media transport. Within the context of TS 23.292 and TS 23.237, the further 3GPP document TS 23.216: “Single Radio Voice Call Continuity (SRVCC); Stage 2”, describes a mechanism for handing over a voice call from a PS to a CS access. With reference to FIG. 1, this relies upon ICS and Service Continuity functionality that is implemented in the Service Centralisation and Continuity Application Server (SCC AS) within the IMS (shown co-located with the MMTel AS in FIG. 1). Whilst effective, the mechanism described in TS 23.216 (identified as Rel-9) involves a relatively long path for handover control signalling given that the SCC AS is located in a user's home network and the signalling may have to pass through an IMS network associated with a visited network (in the case of a roaming subscriber where the serving network is not the home network). Handovers may be delayed as a result, possibly giving rise to interruptions in voice calls. SRVCC is applicable to handover to a CS access from a PS access where that PS access is provided by either of a LTE access or a UTRAN (HSPA) access.
It has been recognised that such a long path for access handover related signalling is undesirable. This problem is addressed in TS 23.237, “IP Multimedia Subsystem (IMS) Service Continuity”, which proposes introducing the architecture illustrated in FIG. 2. An Access Transfer Control Function (ATCF) is included in the serving (e.g. visited) IMS network. This approach is referred to as Rel-10. According to Rel-10, the ATCF acts as a media gateway controller for an Access Transfer Gateway (ATGW) that is also present in the serving IMS network. The ATGW acts as an anchor for the IMS media traffic to allow media traffic to be switched quickly from the PS access network to the CS access network via the MSC. Additional functions of IMS Service Continuity are provided by the ATCF/ATGW in the serving (visited if roaming) network. In particular, responsibility for managing radio access handovers is delegated from the SCC AS to the ATGW. Within the CS core network, a SRVCC function is introduced into one of the network MSCs. This may or may not be the same MSC as the Target MSC for the handover.
When the UE performs IMS registration, a decision is made (by the P-CSCF) as to whether or not to include the ATCF in the path. If the ATCF is included, the ATCF reports a Session Transfer Number Single Radio (STN-SR) to the SCC AS in the home IMS network. This STN-SR is recorded by the SCC-AS in the HSS in respect of the ongoing IMS session. The STN-SR points uniquely to the ATCF. When the UE is either initiating or receiving an incoming call, the ATCF makes a decision concerning whether or not to anchor the media in the controlled ATGW. If the media is anchored at the ATGW, then, when an access handover takes place, the redirection of media to the new access will be carried out locally in the serving (e.g. visited) network. The anchored media in the ATGW is redirected to the CS side instead of the PS side.
According to the LTE architecture described with reference to FIG. 2, a VoLTE call is anchored in an ATFC/ATGW function residing between the P-CSCF and the S-CSCF of the served user. In the event of a handover of a UE served by the ATCF, there is no requirement to inform the remote end beyond the SCC-AS point that handover has taken place (in order to shorten voice interruption time), especially as the type of communication, i.e. voice, has not changed. A problem will arise however in the event that handover results in a change to the session capabilities.
The architecture described may result in the remote end (UE) of the VoLTE session remaining under the impression that voice session add-on services are still possible despite this no longer being the case as a result of the handover from PS to CS access. For example if an add-video capability was exchanged during the voice establishment phase—as it may be according to GSMA PRD IR.94—the remote end UE might continue to have a ‘switch-to-video’ or ‘video upgrade’ icon highlighted in its call window after handover. If the remote end-user selects switch-to-video, that attempt will fail due to the inability of the CS call leg to support video.